1. Field of Invention
This invention relates in general to software, and more particularly, to software debugging.
2. Description of Background
A common and often challenging problem in software debugging is backtracking to understand how the system has arrived at a particularly state. This is generally not the first step in the debugging process. First, particularly for complex programs, a lot of study is sometimes needed just to understand what the system's state is when misbehavior becomes apparent. The result of this study is called setting a good breakpoint. The real challenge comes after this step, when one must next understand how the system has come to be in this misbehaving state. There's often no clear way to identify relevant breakpoints that will trigger before there's any apparent misbehavior. Software developers may spend hours or days, using hit-or-miss techniques, to pin down the entire chain of events leading up to the misbehavior they are trying to debug.
A host of development tools is marketed to help circumvent or address this breaktracking challenge. Some tools point our programmatic errors or race conditions that can lead to certain classes of problems, but none of these tools will identify every sort of problem so that it can be circumvented. Other tools capture total state information throughout the run, but such tools must record an overwhelming amount of state data, making them inadvisable for some complex programs. Developers often simply log selected program state data, but the data logging mechanism must be developed, and appropriate data must be selected for logging. Deploying any of the foregoing tools or techniques in the field may result in customer frustration if the source of the problem is not readily diagnosed that way.
Thus, there is a need for partial program state capture that does not require stepping backward in the debugging.